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PREFACE 


In  order  to  dc  well  ir.  a  position,  a  person  must  bring  two  factors  to  that 
position:  native  intelligence,  and  experience.  Combined,  the  two  will  equal 
that  person’s  ski 1 1  ir.  fulfilling  his  responsibilities  most  effectively. 

Kative  intelligence  is  more  or  less  a  fixed  item,  but  experience  is  not. 
Experience  can  be  acquired  in  two  ways,  each  of  which  supplements  the  other. 

The  first  way  is  actual  on-the-job  work.  The  second  way  is  by  reading  about 
how  ethers  have  done  similar  tasks. 

The  persons  vho  have  been  associated  in  the  development  of  the  production 
process  described  in  this  paper  have  accumulated  a  total  of  over  forty  man-years 
of  experience  in  the  management  of  large-scale  computer  program  system  production. 
I  .'early  half  of  this  has  been  with  the  largest  computer  program  system  being 
produced  -  the  4651.  Planning  Subsystem. 

$ 

(The  465L  Planning  Subsystem  is  one  of  the  two  operational  Components  that 
make  up  the  46 5 L  System.  The  other  component  is  the  465L  Control  Subsystem. 

As  their  names  imply,  these  will  perform  planning  and  control  functions, 
respectively,  for  the  Strategic  Air  Command.  Each  of  these  subsystems,  alone, 
is  in  itself  a  large  integrated  program  system.  The  Planning  Subsystem,  in 
itself,  is  comprised  of  approximately  90  programs,  300,000  machine  instructions, 
and  a  data  base  of  6,000,000  words.  They  are  called  subsystems  only  because 
they  are  components  of  the  total  465L  System. ) 

We  hope  that  our  experience  can  be  of  help  to  the  managers  of  other  current 
and  future  computer  programming  projects.  The  record  of  how  we  set  up  and 
controlled  the  production  process  for  the  Planning  Subsystem  provides  insights 
into  the  nature  of  the  problems  involved,  and  into  some  of  the  ways  by  which 
these  problems  may  be  overcome. 

We  recognize  that  this  paper  i3  not  a  generalized  description  of  the  program 
production’  process,  however,  ve  do  feel  it  to  be  a  significant  milestone  in 
that  it  is  a  positive  attempt  at  defining  or  analyzing  computer  programming 
In  terms  of  activities,  products,  needed  resources,  and  management  controls. 

This  paper,  then.  Is  dedicated  to  those  who  take  on  the  heavy  burden  of 
managing  the  production  *of  a  large  computer  program  system.  This  task  is  not 
easy,  but  it  f.  a  ehal'ongc  that  brings  a  most  rewarding  feeling  when  It  is 
aeeomp!  I  s'ncU  r.:. ■•eeusfuj  ly. 
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1.  introduction 

•  ^-3.  _  +■  ' 

M  Ollier  to  effectively  manage  the  production  process  cf  a  large-scale 
e&Spdier  program  stSbsyStda,  c<ne  must  first  have  a  clear  definition  of  the 
process.  This  paper  defines  the  process  used  in  producing  the  h65L  Planning 
l&bsyatem.  Use  total  production  process,  needless  to  say,  requires  a  manager’s 
attention  to  a  great  many  functions,  e.g.,  processing  and  controlling  system 
Changes,  effective  utilization  of  manpower  resources,  effective  EAM/EDFM 
utilisation,  etc,  Although  these  are  all  integral  parts  of  the  total,  process, 
in  this  paper  we  restricting  ourselves  to  a  definition  cf  the  basic  func¬ 
tions  of  the  production  process.  Furthermore,  th«*  production  process,  as  it 
is  defined  in  this  paper,  assumes  certain  functions  hat  precede  the  process 
and  thus  produce  inputs  to  it,  and  certain  functions  *hat  follow  the  production 
process  and  thus  utilize  Its  outputs. 

Inputs  To  Production  Process  -  This  process  start?  or  -eeeipt  of  (l )  a  System 
Integration  Document,  specifying  the* formats  of  tre  user  input  messages  and 
output  displays;  and  (2)  Operational  Design  Requirements  (ODR’s)  containing 
the  following  sections:  general  statemen;  and  dej-cri p .  1  on  of  the  requirements; 
logical  designs,  including  assumptions,  ir.  both  prose  and  diagram  form;  specific 
requirements  indicating  the  areas  of  human  interaction  with  the  program;  specifi 
operational  program  requirements. 

ft. 

Ifce  Phases  Of  The  Production  Process  -  The  production  process,  as  defined  in 
this  paper,  i„  divided  inti'  five  basic  phases— Translation,  Design,  Coding, 
Verification  and  Internal  Release.  Each  of  these  phases  is  essentially  a 
building  block;  „hc  outputs  of  one  phase  are  the  inputs  to  the  next.  Interim 
documents  serve  a>  bench-marks  to  signal  the  completion  of  each  phase.  These 
documents  serve  four  functions: 

1.  le  in  .net  programmers  perform  °ack  r  rp  fr,  a  rigorous  fashion; 

2.  To  c.vur.  .*»  •  -al  supe~vi oors  to  inspec  intermediate  steps  so  as 
to  insure  a  r.lgi.  quality  product; 

3.  to  enuo  v  ’.re  managers  to  more  accurate.’ y  use'-ss  where  the  develop¬ 
ment  cf  tr.f  subsystem  stands  ir.  relation  to  «ucre  it  should  be,  and 
^  on  sequent,  if  to  better  assess  future  manpower  needs  and  delivery 
dates ; 

1 .  Minimise  ‘ho  impact  of  manpower  turnover,  slice  most  of  the  develop¬ 
ment  is  recorded  in  documentation. 

Jut  puts  From  Ihe  Production  Process  -  Tills  definition  assumes  that  the 
production  process  is  completed  after  the  Internal  Release  Phase.  It  is 
assumed  that  there  vi.,.1  be  some  other  agency  which  will  then  take  the  product 
a..d:  perform  subsystem  testing;  install  the  subsystem  in  a  computer  at  a 
given  location;  formally  release  the  product  to  the  customer. 
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If.  TllAftSLaTIOH  PHATl' 


The  Translation  Phase  has  Pilfer,  purposes: 


1.  To  give  programmers  a  clear  understanding  of  the  content  of  the  Operational 
Deal gn  Requi  remer. ts  ( 0 >: ' s } ; 

2.  To  identify  and  resolve  inconsistencies  in  the  OCR's; 

3.  To  re-group  the  Sanctions  stated  in  the  OCR's  so  that  they  are  logically 
grouped  from  a  programming  point  of  view. 

Problems  In  Translation  And  Their  Solution 

""" . — . . g"1  - -  — 

Translation  of  the  OCR’s  is  by  no  means  easy,  when  thousands  of  pages  of 
requirements  and  seventy  cr  more  programmers  are  involved.  Experience  has 
shown  that  there:  is  a  diversity  in  the  understanding  of  the  OCR's  because 
people  enpnasJue  different  tr.!ngs  in  their  reading,  and  since  there  is 
frequent  y  s  varying  oepre  ef  ne-ai?  in  different  OCT.'s. 

Lut  in  this  pnasc,  uniformity  is  important  This  .‘an  be  achieved  by: 

* 

1.  The  proceauri.tinj  of  the  War.jiacior  Phase  into  steps  with  definite 
objectives  at  the  er.a  of  le.t.  step,  and 

2.  '.Tie  e  st  ab  1  is;  inter  t  of  .wo  dor.  men  tat  ion  points  Vo  r.’gn  fy  the  mid-point 
and  tne  end  of  the  Trans’ at’  r  Phase. 
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The  Translation  Hiase  is  comprised  of  both  analysis  (i.e.t  the  breaking  up  of 
a  whole  into  its  component  parts  to  ascertain  tneir  nature)  and  synthesis 
(l.e. ,  the  combining  of  parts  to  form  a  whole.)  Analysis  consists  of  three 
steps  (which  satisfy  ue  first  two  purposes  of  the  Translation  Phase— to 
obtain  a  clear  understanding  of  the  ODK's,  and  to  identify  and  resolve  incon¬ 
sistencies  in  the  Cif-1 3. ) 

1.  Segmentation  of  CflR's  into  functional  areas; 

2.  Identification  of  ODR  subfunctions  (QoF's); 

3.  Performance  of  detailed  analysis  of  each  ODR  subfunction. 

Siynthesis  consists  of  two  steps  (which  satisfy  the  third  purpose  of  the 
Translation  Phase— to  re-group  the  functions  stated  in  the  ODR's  so  that  they 
are  logically  related  from  a  programming  point  of  view.) 

k.  Rie  synthesis  ol  logical  tasks  from  ODF  subfunctions; 

5.  The  synthesis  of  logical  Jobs  from  logical  tasks, and  the  documentation  of 
the  Preliminary  Program  Subsystem  Specification. 


Figure  4 
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Step  1— Segnentatlon  Of  OCR's  Into  Functional  Areas 

As  stated  above,  the  Inputs  to  the  Translation  Phase  for  the  Planning  Subsystem 
are  OCR's  and  the  System  Integration  Document. 

The  first  step,  then,  involves  the  analysis  of  the  ODR's,  in  order  to  define 
logical  subdivisions  of  the  subsystem*  Each  subdivision  consists  of  all,  or 
parts  of,  one  or  more  OCR’s,  end  is  called  a  "functional  area."  The  basic 
criterion  employed  in  defining  these  logical  subdivisions  is  functional  inter¬ 
dependency.  For  example.  In  the  Planning  Subsystem,  1 he  Plight  Plan  Analysis 
functional  area  consists  of  all  or  parts  of  the  OCR*  s  for  Flight  Simulation, 
Airborne  Alert,  Mating  and  Routing.  The  functions  defined  in  these  OCR's  are 
all  involved  in  the  development  of  flight  plans.  "  The  intent  of  this  sub¬ 
division  of  the  subsystem  into  functional  areas  is  to  logically  distribute 
the  work  load  among  the  organizational  sections  comprising  the  group  of 
progrsmssrs  who  are  to  produce  the  subsystem. 

A  gross  sstimste  of  the  scope  (i.e.,  the  number  of  progressing  instructions) 
of  each  functional  area  Is  made,  and  then  one  or  more  of  these  areas  is 
assigned  to  each  section  in  the  group. 
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Step  2— Identification  Of  OCR  Bubfunctlons  (OSF) 

“  ^°.are  ^laJcp  Portions  of  an  ODR  in  detail  - 

♦Uv*11  *  8  10  their  particular  functional  area,  in  order  to  obtain  a 

total  ov*rvi«JJ*t  ®»y  then  participate  in  meetings  to  further  sub-divide 

**Ch  divl8loa  <*  *»  ODR  is  identified  as  an  ODR  sub- 
^ncti<m  (OSP).  The  purpose  of  this  step  is  to  break  down  each  functional 
area  into  sumageable  parts  (GBP's)  so  that  they  can  be  distributed  to  prograa- 

S ified' dSnthdCta1^,  ^y*18 ’  ^-tions  and/or  inconsistencies 
identified  during  the  preliminary  readings  are  coordinated  with  the  ODR  author. 

2?  a«i!^Ctl°n8  T  then  “8igned  t0  Progranaers  for  detailed  analysis. 

coamlexiSTtS  si!!  ^  °*  Pro«rMsaer  capability,  and  the 

cr^wo  OSF’s  1  f  ^  °SF*  Generally,  each  programmer  is  assigned  one 
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Step  3«»PerfonBance  Of  Detailed  Analysis  of  Bach  OPR  Subfunction 

The  programmers  then  begin  detailed  analysis  of  their  assigned  OSF's.  Each 
such  analysis  consists  of  a  careful  reading  of  the  pertinent  operational 
program  requirements  portion  of  the  01®,  to  obtain  a  clearer  understanding  of 
the  processing  therein  described  and  to  identify  the  data  required  for  the 
performance  of  the  OSF.  Each  piece  of  data  is  defined  in  terms  of  its  nature 
(i.e.,  fixed  or  variable),  form,  range,  and  functional  grouping.  For  example, 
aircraft  total  fuel  capacity  might  be  defined  as  fixed,  integer,  50,000  to 
300,000,  and  a  function  of  aircraft  type  and  model. 

In  performing  this  detailed  analysis,  each  progranmer  is  responsible  for  co¬ 
ordinating  with  the  01®  author  to  validate  the  analysis.  Nev  OSF’s  are  some¬ 
times  created  by  consolidating,  redefining  or  splitting  up  old  ones.  Nev 
assignments  of  OSF's  cure  made  when  necessary. 

A  form  of  documentation  helps  insure  that  the  analysis  is  performed  correctly. 
It  signifies  completion  of  analysis,  the  first  part  of  the  Translation  Phase. 
This  fora  of  documentation  ij  the  functional  flow  chart  and  is  essentially  a 
graphic  presentation  of  the  prose  statement  of  requirements.  Programmers  are 
required  to  produce  functional  flow  charts  for  each  OSF.  These  charts  portray 
the  OSF  processing  without  explicitly  relating  it  to  machine  processing. 

(This  explicit  relationship  is  made  in  the  Design  Phase. )  Each  chart  is 
reviewed  by  the  technical  supervisor  for  accuracy  and  uniformity.  The  (cor¬ 
rected)  chart  is  then  reproduced  and  copies  are  given  to  each  programmer 
working  on  the  functional  area  to  enable  him  to  review  it  as  it  relates  to  his 
own  subfunction(s). 
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Step  4- -The  Synthesis  Of  Logical  Tasks  From  OPR  Subfunctions 

Synthesis  begins. with  a  grouping  together  and  identification  of  OSF' s  as 
logical  tasks.  A  logical  task  consists  of  one  or  more  OSF* a  which  collectively 
accomplish  a  specific  SAC  function.  An  example  of  a  logical  task  is  the  Flight 
Simulation  Task.  OSP’s  comprising  a  given  logical  task  might  very  well  have 
originally  been  parts  of  different  OCR's.  For  example,  the  cruise  mode  of 
flight  (a  Flight  Simulation  OCR  subfunction)  and  the  segmentation  of  sortie 
routes  (a  Routing  ODR  subfunction)  both  comprise  part  of  the  same  logical  task  - 
Flight  Simulation.  In  this  step,  calculations  common  throughout  the  OSF's, 
such  as  sine  and  cosine  calculations,  are  identified  for  subsequent  handling 
as  subsystem  routines. 

A  concurrent  activity  is  the  identification  of  logical  groupings  of  the  data 
required  for  performance  of  a  given  logical  task.  The  data  defined  during  the 
previous  step  for  each  OSF  are  collected  into  sets  by  their  functional  groupings, 
(e.g.,  all  data  which  are  a  function  of  aircraft  type  and  model  are  collected 
into  a  single  set. ) 
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Step  5--The  Syntheals  Of  Logical  Jobs  From  Logical  Tasks,  And  The  Documentation 
6f  fee  Preliminary  Program  Subsystem  Specification 

All  logical  tasks  developed  within  the  subsystem  are  then  analyzed  and  grouped 
into  logical  Jobs.  A  logical  job  is  composed  of  one  or  more  logical  tasks 
which  must  operate  together  to  fulfill  a  class  of  related  user  input  messages. 

She  basic  criterion  for  establishing  logical  jobs,  then,  is  man-machine  inter¬ 
action.^  An  example  of  a  logical  job  is  the  Input  Processor  Logical  Task  and 
the  Flight  Simulation  Logical  Task  mentioned  above.  (For  example,  the  Input 
Processor  Logical  Task  would  be  identified  at  this  step  in  the  development 
since  analysis  of  all  previously  developed  logical  tasks  would  indicate  that 
each  is  performing  an  input  processing  function  and  that  it  would  be  reason¬ 
able  to  centralize  and  generalize  this  function.) 

A  parallel  effort,  one  closely  related  to  the  development  of  Jobs,  is  the 
further  development  of  the  data  base.  The  data  sets  previously  identified 
for  the  logical  tasks  are  now  merged  to  fora  larger  data  sets  for  the  entire 
subsystem.  To  illustrate,  let  us  assume  that  two  functional  areas  ~e quire 
data  associated  with  aircraft  units.  The  first  requires  the  units'  locations 
and  configurations;  the  second  requires  the  units'  locations  and  vulnerabilities. 
At  this  time,  the  common  data  requirement  would  be  recognized  and  one  data  set 
for  units  would  be  established,  consisting  of  units1  locations,  configurations, 
and  vulnerabilities. 

The  results  of  the  Translation  Phase  are  documented  in  the  "Preliminary  Program 
Subsystem  Specification."  Ihis  document  identifies  the  logical  tasks  and  Jobs, 
the  data  sets,  and  the  input  and  output  requirements  of  the  subsystem.  It  also 
contains  prose  and  graphic  descriptions  of  the  manner  in  which  the  various 
logical  tasks  and  jobs  relate.  Publication  of  this  document  signals  the 
completion  of  the  Translation  Phase. 


1  fee  human  action  requirements  portion  of  the  ODR*s,  and  the  8y«tem 
Integration  Document,  assist  in  defining  this  man-machine  interaction. 
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III.  DESIGN  PHASE 


Purpose  Of  The  Design  Phase 

The  Design  Phase,  though  simple  in  definition,  is  perhaps  the  most  complex 
and  significant  phase  of  programming.  Its  purpose  is  to  structure  the  actual 
Jobs,  tasks,  and  programs  that  comprise  the  subsystem,  in  order  to  produce  the 
most  efficient  and  least  costly  subsystem  possible. 

Problems  In  Design  And  Their  Solution 


The  orderly  and  generally  accepted  approach  to  program  system  design  is  to 
work  from  the  general  to  the  specific.  In  our  subsystem,  this  means  first 
designing  Jobs,  then  tasks,  then  programs.  The  problem,  however,  is  that  in 
actual  practice,  programmers  tend  to  concentrate  effort  on  the  design  of  the 
most  specific  components  (i . e. ,  programs)  since  these  are  the  easiest  to  grasp 
and  also  seem  to  most  directly  affect  the  progress  of  subsystem  development. 
This  means,  then,  that  the  design  of  Jobs  and  tasks  may  be  left  for  last,  and 
thus  be  hurried  and,  consequently,  inefficient .  Experience  has  demonstrated 
that  inefficient  Job  and  task  design  results  in  redundant  efforts  in  design, 
coding  and  verification,  extensive  rework  in  coding  and  verification,  and 
attendant  low  programmer  morale. 

A  solution  to  this  problem  is  to  procedurize  the  Design  Phase  and  to  establish 
interim  bench-marks  insuring  that  each  step  of  the  process  is  performed 
adequately. 
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Inputs  to  the  Design  Phase,  in  addition  to  the  outputs  from  the  Translation 
Phase  (i.e. ,  Preliminary  Program  Subsystem  Specification,  and  Functional  Flow 
Charts)  include  the  System  Integration  Document  and  Operational  Design  Require¬ 
ments  (OOR's)  that  were  also  input  to  the  Translation  Phase. 


The  following  steps  comprise  the  Design  Phase: 


1.  Job  Design  * 

2.  Preliminary  Task  Design 

3.  Detailed  Task  Design 

4.  Preliminary  Program  Design 

5.  Quality  Review  and  Production  of  Preliminary  Task  and  Program  Design 
Specifications 

6.  Detailed  Data  Analysis 

7.  Detailed  Program  Design 
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Stop  One— Job  Design 

Given  the  logical  jobs  produced  in  the  Translation  Phase  and  documented  in  the 
Preliminary  Program  Subsystem  Specification,  the  function  of  Job  Design  is  to 
determine  whether  the  logical  Jobs  can  be  actual  jobs.  (In  the  Translation 
Phase,  machine  constraints  were  not  explicitly  considered.  This  would  have 
been  an  additional  factor  of  complexity  at  that  initial  phase.  It  was  decided 
that  for  the  sake  of  maximum  efficiency,  the  consideration  of  these  factors 
should  be  left  to  the  Design  Phase. ) 

The  primary  machine  constraint  considered  in  Job  Design  is  the  amount  and  type 
of  auxiliary  storage  (i.e.,  tapes,  disc,  drums)  available  to  the  subsystem. 
Since,  by  definition,  no  human  intervention  is  permitted  during  the  operation 
of  a  job,  the  required  auxiliary  storage  configuration  cannot  exceed  that  which 
is  available.  For  example,  if  a  maximum  of  ten  tape  drives  is  available  to  the 

subsystem,  no  desired  auxiliary  storage  configuration  can  exceed  ten  tapes. 

«*  • 

The  first  thing,  then,  that  must  be  done  for  each  logical  Job  is  to  determine 
the  required  auxiliary  storage  configuration.  The  data  sets  defined  in  the 
Preliminary  Program  Subsystem  Specification  are  re-analyzed  for  pertinency  to 
the  given  job.  The  maximum  size  of  each  pertinent  data  set  (e.g.,  the  maximum 
number  of  missile  units)  is  used  to  determine  the  amount  of  auxiliary  storage 
required  for  that  data  set.  The  data  sets  are  organized  into  tape  files,  drum 
files,  and  disc  data  units.  The  tape  files  are  grouped  so  as  to  form  logical 
tapes. 

If  the  desired  auxiliary  storage  does  not  exceed  that  which  is  available,  the 
logical  job  can  be  an  actual  job.  If  it  does  exceed,  an  attempt  is  made  to 
change  the  desired  auxiliary  storage  -  by  re-allocating  files  -  and  thereby 
forcing  a  fit.  If  this  attempt  fails,  the  logical  job  is  either  redefined  or 
split  into  two  or  more  logical  jobs  and  the  process  of  Job  Design  starts  over 
again.  Since  the  criterion  for  establishing  jobs  was  human  interaction, 
whenever  new  jobs  are  created,  they  must  be  coordinated  with  the  ODR  authors 
to  insure  feasibility  from  the  point  of  view  of  the  user. 

The  completion  of  Job  Design  is  marked  by  the  production  of  job  flows  which 
identify  the  gross  auxiliary  storage  configuration  required  for  each  Job. 
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Step  Two-«?relicfnary  Task  Design 

the  function  of  Preliminary  Task  Design  is  to  design  actual  tasks  from  the 
logical  tasks  developed  in  the  Translation  Phase.  Hie  primary  programing 
constraint  is  available  core  memory  space  (to  be  distinguished  from  available 
auxiliary  storage.  1  e. ,  tapes,  disc,  drums,  space,  which  was  the  constraint 
in  the  preceding  s„ep.) 

A  preliminary  analysis  of  the  Job  flow  for  the  actual  Job  and  of  the  associated 
logical  task  definitions  is  performed  to  determine  which  of  the  data  now  de¬ 
fined  on  tape,  disc  and  drum  are  required  for  a  given  task's  operation. 

Hie  maximum  size,  of  the  required  data  in  core  is  then  determined.  This  maximum 
size  can  differ  from  the  size  of  files"  since"  not  all  the  data  contained  in  the 
files  are  necessarily  required  at  the  same  time  in  core  for  calculations.  For 
example,  a  file  might  contain  data  defining  all  missile  units,  but  the  logical 
task  would  require,  at  any  given  time,  only  the  data  defining  one  unit. 

The  total  required  amount  of  core  is  then  computed.  This  is  done  by  adding 
the  amount  of  core  required  for  the  data,  to  an  estimated  amount  required  for 
the  instruct  ons  which  will  accomplish"  the  data  functions.  If  this  total 
required  amount"  does  not  exceed  the  amount  of  core  available,  then  the  logical 
task  can  become  an  actual  task.  Otherwise,  re-analysis  must  be  made  to  reduce 
the  amount  of  data  and/or  the  number  of  instructions  required  in  core  for  the 
task.  Factors 'considered  include  the  relationship  (f.e.,  is  the  task  linear, 
iterative,  or  a  combination),  the  complexity,  and  the  size  of  each  function  of 
the  task. 

If  this  ro-analyci  r;  indicates  that  the  task  or  data  can  be  redesigned  to  fit 
into  core,  then  the  logical  tack  can  become  an  actual  task.  Otherwise,  the 
Logical  task, must  be  split  into  two  or  more  logical  tasks  and  the  process  of 
Task  Design  starts  again. 

Nex%  task  designers  assess  all  changes  that  have  been  made  to  the  data  files. 
This  leads  to  integration  of  data  and/dr  redefinition  of  tasks. 

The  completion  of  Prel  iminnry  Task  Design  is  marked  by  the  production  of  the 
gross  task  data  requirements,  both  in  terms  of  gross  core  configurations  and 
data  transfers. 
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Given  actual  tasks  and  gross  data  requirements,  the  functions  of  this  step 
are  to  associate  the  computer  functions  necessary  to  accomplish  the  given  task 
function*  and  to  fraction  the  task  into  programs. 


Computer  functions  such  as  reading,  writing,  sorting  and  searching  are  associ¬ 
ated  (wherever  necessary)  with  the  operational  functions  identified  in  the 
Translation  Phase.  This  complete  set  of  functions  is  illustrated  in  an  initial 
task  flow. 


This  initial  task  flow  is  analyzed  to  determine  whether  a  single  program  would 
be  sufficient  to  perform  the  processing  required  to  satisfy  all  functions.  (A 
single  program  would  be  sufficient  if  the  amount  of  processing  is  small,  or  is 
not  readily  split  into  logical  entities. )  If  a  single  program  sufficies,  design 
proceeds  with  a  determination  of  the  data  flow  and  the  preparation  of  a  more 
specific  form  of  the  task  flow  (the  preliminary  task  I/O  flow  chart . ) 


If  a  single  program  does  not  suffice,  the  initial  task  flow  is  then  further 
analyzed  to  determine  the  concept  of  task  design  to  be  employed.  There  are 
two  such  concepts.  One  (the  "control  program"  concept)  is  to  have  one  program 
control  the  operation  of  all  other  programs.  The  other  (the  "independence" 
concept)  is  to  have  each  program  operate  relatively  independently  of  the  others. 
Factors  which  argue  for  the  adoption  of  the  "control  program"  concept  are  a 
non-linear  order  of  task  function  operation  and  a  significant  amount  of  common 
processing. 


Once  the  concept  has  been  determined,  the  design  proceeds  with  a  more  detailed 
analysis  of  the  data  flow  and  a  concurrent  identification  of  programs.  This 
process  considers  various  constraints  imposed  by  the  physical  configuration  of 
the  machine  and  by  the  System  Control  Program  (the  "Executive"  in  the  46% 
System.)  The  programs  will  consist  of  subsets  of  the  functions  performed  by 
the  task. 


Task  designers  in  each  functional  area  identify  cannon  functions  -  and,  there¬ 
fore,  programs  -  and  insure  that  there  is  a  consistent  data  base.  Throughout 
the  Design  Phase,  programmers  whose  sole  responsibility  is  to  insure  a  consistent 
and  efficient  data  base  are  working  with  representatives  of  each  functional  area 
toward  that  end. 


The  completion  of  Detailed  Task  Design  is  signaled  by  the  production  of  the 
preliminary  task  I/O  flow  charts  and  identification  of  each  program. 


Figure  lh 
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Step  Fc?ur-»PrcIimlnary  Program  Design 

The  functions  of  this  step  ere  to  produce  preliminary  program  design  flows 
(from  the  functional  flow  charts  and  added  computer  functions)  and  to  structure 
the  tables  containing  the  data  to  be  processed.  The  more  important  constraints 
axe  imposed  hy  types  of  table  structures  and  tagging  conventions  which  must  he 
adhered  to. '  Close  coordination  is  mandatory  since  many  programs  process  the 
same  data. 

Completion  of  this  step  is  indicated  by  the  production  of  preliminary  program 
design  flows  and  preliminary  table  structures. 


« 
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The  preliminary  design  of  oil  programs  tad  tablet,  and  the  detailed  design  of 
•11  tuks,  ere  reviewed  at  a  series  of  quality  review  Meetings  which  are 
attsmgH  hy  re^reseatatiwes  from  all  functional  areas*  The  purpose  of  these 
Meetings  is  three- fold: 


1.  TO  eliminate  future  redundant  prngr— ling  efforts; 


2.  To  detemlne  if  computer  functions  are  being  accomplished  at  the  most 
opportune  points; 

3*  TO  Insure  that  the  quality  of  the  product  Is  high* 


Upon  c  caplet  ion  of  these  Meetings,  the  prograMB,  tasks,  and  Jobs  are  revised 
as  necessary  and  are  documented  in  accordance  with  detailed  AocuMent  format 
guidance.  The  preliminary  Program  Design  Specifications  include,  for  each 
program,  a  statement  of  the  program's  responsibility,  a  description  of  Its 
environment,  and  a  program  design  flow.  The  preliminary  Task  Design  Specifi¬ 
cation  includes  a  description  of  the  task's  responsibility,  a  description  of 
its  environment,  its  outputs,  core  configurations,  auxiliary  storage  config¬ 
urations,  I/O  flow  and  a  detailed  description  of  the  lfD  Slow,  The  detailed 
Job  flows  are  prepared  for  later  inclusion  in  the.  Pinal  Program  Subsystem 
Specification. 
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Step  8136— Detailed  Data  Analysis 

t 

The  function*  of  this  step  are  to  fix  data  definitions  and  to  record  the  data 
in  the  data  dictionary  (known  as  the  "Caapool"  in  the  465I>  System. )  Each  item 
in  each  table  is  coordinated  and  fully  defined.  Data  Specification  Request 
(BSE)  forms  are  filled  out  for  each  item,  table  and  file.  Data  are  legality 
checked  and  modifications  made  where  necessary.  The  data  are  than  placed  onto 
the  Ccmpool  tape  and  listings  are  produced. 

From  this  point  in  the  production  process,  the  data  base  ia  fairly  static,  and 
changes  are  made  on  a  more  formal  basis  (i.e.,  by  coordinating  and  submitting 
written  change  requests  or  DGR's.) 
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Step  Seven— Detailed  Program  Design 
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IV.  CODIHC  PHASE 


Purpose  Of  The  Coding  Phase 

The  purpose  of  this  phase  Is  to  translate  programs  heretofore  defined  in 
terms  of  design  specifications  and  detailed  program  flows,  into  sets  of 
higher  order  language  statements,  and  to  compile  sets  of  machine  language 
instructions  from  these  higher  order  language  statements. 

Problems  In  Coding  And  Their  Solution 

Experience  has  shown  that  many  problems  arise  because  of  the  size  and  complex¬ 
ity  of  the  program  subsystem,  and  because  of  inexperienced  programmers.  Some 
of  these  problems  are  production  of  inefficient  code  (and  consequent  lengthening 
of  the  Verification  Phase),  and  improper  utilization  of  EAM  and  HffM  facilities. 
A  way  of  minimizing  these  problems  is  to  procedurize  the  Coding  Phase. 
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Methodology  Of  Coding 

la  general,  the  inputs  to  this  phase  are  the  detailed  prograa  flow  charts, 
the  Prograa  Design  Specifications,  and  the  complete  data  definitions. 

Coding  starts  with  the  translation  of  the  logical  statements,  contained  on 
the  detailed  program  flow  diagrams,  into  equivalent  JOVIAL  higher  order 
language  statements.  These  higher  order  language  statements  are  punched  onto 
cards.  The  decks  of  cards  are  then  submitted  for  compilation,  and  errors  are 
corrected  until  an  error- free  binary  deck  is  obtained. 

Adherence  to  coding  conventions  and  procedures,  frequent  review  of  the  product 
by  the  technical  supervisor,  and  the  fact  that  much  of  the  work  usually  done 
in  the  Coding  Phase  has  already  been  done  as  the  last  part  of  the  Design  Phase, 
are  sufficient  to  insure  optimum  progress. 
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V.  VERIFICATION  PHASE 


Purpose  Of  The  Verification  Phase 

The  purpose  of  this  phase  is  to  purge  the  program  subsystem  of  errors.  The 
goal  of  verification  is  to  produce  an  error-free  subsystem.  It  should  be 
noted,  however,  that  this  is  a  goal  which  is  never  totally  realized.  In 
striving  towards  this  goal,  the  producer  of  a  large  computer  program  subsystem 
corrects  all  the  errors  he  detects  as  a  result  of  running  a  set  of  preplanned 
test  cases.  The  realities  of  life  prevent  him  front  verifying  the  literally 
mi 11 lone  of  possible  paths  through  the  subsystem. 

Problems  In  Verification  And  Their  Solution 

Historically,  in  this  phase,  production  efforts  bog  down  and  schedules  slip. 
Many  reasons  are  presented  to  rationalize  this  problem.  Examples  are  the 
complexity  and  size  of  the  program  subsystem  and  the  inexperience  of  the 
programmers  involved.  But  perhaps  more  basic  causes  of  this  problem  are  the 
absence  of  a  defined  verification  methodology  and  the  consequent  inability  of 
management  to  accurately  assess  progress  and  thereby  to  control  production. 

If  there  is  no  organized  approach,  programmers  tend  to  over- verify  seme  areas 
and  neglect  others. 

A  solution  is  a  system  approach  to  verification,  one  in  which  levels  of  veri¬ 
fication  arc  introduced  and  for  which,  within  each  level,  a  well-defined 
procedure  is  established.  The  keys  to-  establishing  the  procedures  are  the 
designation  of  a  specific  goal  for  each  level  of  verification  and  the  identi¬ 
fication  of  interim  products  in  the  verification  process.  The  interim  products 
provide  for  manager! aJ  inspection  and  allow  the  programmer  to  direct  his  work 
toward  the  stated  goal. 
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Methodology  Of  Verification 

The  system  approach  to  verification  relates  directly  to  the  manner  in  vhich 
the  program  subsystem  has  thus  far  been  developed  and  documented.  First, 
the  system  designers  generated  and  published  OK's.  Given  these  ODR’s,  the 
prognmners  designed  tasks,  then  programs.  They  documented  these  in  Task  aid. 
Program  Design  Specifications.  The  "functions  vhich  are  to  be  tested"  are 
also  documented  at  each  level;  i.e.,  system  performance  requirements,  task 
verification  matrices,  and  program  verification  matrices. 

The  approach,  then,  is  to  verify  against  each  of  the  three  levels  of  specifi¬ 
cations.  At  the  three  levels,  essentially  the  same  set  of  instructions  is 
being  verified  against  three  different  sots  of  criteria. 

Starting  with  the  level  of  greatest  detail,  and'  utilizing  the  program  verifi¬ 
cation  matrices,  programs  are  verified  against  Program  Design  Specifications. 

The  manipulation  of  data  in  core  is  verified. 

Utilizing  the  task  verification-matrices,  tasks  are  then  verified  against  Task 
Design  Specifications.  Core-to-l/0  device  and  I/O  device- to-core  data  transfers, 
and  program  intercaonunlcation  are  verified. 

Finally,  utilizing  the  system  performance  requirements,  the  program  subsystem 
is  verified  against  the  Operational  Design  Requirements.  This  level  of  testing 
is  performed  following  the  Internal  Release  Phase,  and  is  therefore  not  covered 
in  this  paper. 


PROGRAM  VERIFICATION 
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Program  Verification 

The  specific  goal  of  program  verification  is  to  verify  each  branch  of  each 
program  decision  point.  Satisfaction  of  this  goal  insures  the  code's 
compatibility  with  the  detailed  program  flow  and  verifies  that  the  logic 
specified  in  the  Design  Phase  is  actually  coded  into  the  program.  The 
inputs  to  program  verification  include  the  detailed  program  flow,  Program 
Design  Specifications,  data  specifications,  subsystem  verification  model 
(discussed  below),  and,  of  course,  the  JOVIAL  program  deck.  There  are  two 
basic  steps  in  program  verification,  the  preparation  of  a  plan  and  the  actual 
verification  on  the  computer. 
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The  first  step  of  the  procedure  is  the  preparation  of  a  verification  plan. 
The  verification  plan  consists  of  three  elements: 


1.  a  decision  point  matrix 

2.  test  lists 

3.  inputs  and  expected  outputs 
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The  decision  point  matrix  is  a  device  for  presenting  the  program  decision 
points  in  tabular  form.  Every  decision  point  on  the  detailed  program  flow 
is  labeled.  If  there  is  a  corresponding  symbolic  region  label  in  the  code, 
then  the  same  label  will  appear  on  the  flow  (e.g.,  AA05),  otherwise  a  unique 
label  will  appear  (e.g.,  A/64. )  The  decision  point  labels  are  listed  vertically 
on  the  matrix.  Then,  for  each  decision  point,  each  branch  is  listed  horizon¬ 
tally. 
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Next,  the  determination  is  made  as  to  which  branches  of  which  decision  points 
are  to  be  activated  in  .the  first  test.  These  decisions  and  these  branches 
are  indicated  on  a  test  list.  Ihe  same  form  and  method  of  presentation  is 
used  both  for  the  decision  point  matrix  and  the  test  list.  The  header 
information  on  the  form  allows  one  to  specify  the  "type"  of  use  along  with 
associated  information  (e.g.,  Test  Number  and  Test  Weight.)  Next,  the  number 
of  branches  not  yet  activated  is  determined  and  additional  tests  (and  test 
lists)  are  prepared.  The  fact  that  "paths"  or  combinations  of  branches  have 
cumulative  effects  is  recognized  and  as  many  paths  as  time  permits  are 
incorporated  into  the  test  lists. 

In  order  to  effectively  prepare  these  test  lists,  a  great  deal  of  desk  checking 
is  performed  on  the  program's  logic.  Errors  found  here  can  greatly  minimize 
the  time  required  for  the  actual  verification  on  the  computer. 
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Upon  completion  of  the  test  lists  the  inputs  necessary  to  activate  the 
branches  specified  In  the  test  lists  are  generated  and  recorded.  Wherever 
possible,  these  inputs  are  taken  from  the  subsystem  verification  model.  The 
subsystem  verification  model  is  a  collection  of  representative  data  which 
describes  the  subsystem  in  miniature.  In  the  Planning  Subsystem  it  contains 
a  sample  attack  force,  a  sample  target  system  and  the  characteristics  and 
capabilities  of  each.  The  usage  of  the  verification  model  data  Insures  a 
common  basis  for  verification  as  will  be  explained  in  the  discussion  of  Task 
Verification. 

The  expected  outputs  are  then  manually  computed  and  recorded.  The  verifica¬ 
tion  plan  is  reviewed  for  completeness  and  accuracy  by  the  technical  super¬ 
visor  and  revisions  are  made  as  needed. 

Test  weights  are  attached  to  each  of  the  teats  as  a  function  of  their  site 
and  complexity.  The  application  of  test  weights  facilitates  a  detailed 
schedule  for  verification.  For  example,  if  three  tests  were  planned,  the 
first  weighted  at  50,  the  second  at  30,  end  the  third  at  20,  and  if  the 
program  is  to  be  tested  in  ten  weeks,  then,  in  order  for  the  schedule  to  be 
maintained,  the  first  test  should  be  completed  after  five  weeks,  the  second 
after  eight,  the  third  after  ten.  This  detailed  schedule  pezmits.  the  manager 
to  more  closely  assess  program  verification  progress. 

The  second  step  in  Program  Verification  is  the  actual  verification  of  the 
program.  Eacn  test  is  run  on  the  computer  and  expected  outputs  are  compered 
with  actual  outputs.  Variances  are  noted  and  then  causes  are  searched  out  and 
corrected.  The  program  is  considered  to  be  verified  when  all  expected  outputs 
and  actual  outputs  agree. 
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Task  Verification 


The  specific  goal  of  Task  Verification  is  to  insure  that  each  program  inter¬ 
action  and  each  I/O  operation  functions  properly.  The  inputs  to  Task  Verifi¬ 
cation  include  the  verified  JOVIAL  program  decks,  Task  Design  Specifications, 
data  specifications,  and  the  subsystem  verification  model. 

In  Task  Verification,  as  in  Program  Verification,  there  are  two  basic  steps, 
i.e.,  preparation  of  a  plan  and  the  actual  verification  on  the  machine. 

The  first  step  is  the  creation  of  a  verification  plan.  As  stated  above,  a 
specific  goal  of  task  verification  is  to  insure  that  each  I/O  operation 
functions  properly.  This  is  accomplished  by  insuring  that  each  sequence 
parameter  (discussed  below)  is  activated. 
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Sequence  parameters  are  higher  order  language  sta.tcn.ent 6  which  cause  programs 
to  be  operated  and  I/O  operations  to  be  performed.  They  are  the  medium  in 
which  tasks  arc  coded.  These  statements  are  prepared  from  a  sequence  para¬ 
meter  matrix  which  graphically  portrays  each  operation  and  the  order  in  which 
it  is  to  be  accomplished.  This  sequence  parameter  matrix  is  used  as  the  task 
verification  matrix. 
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Test  lists  ir.di eating  which  sequence  parameters  are  to  be  activated  for  each 
test  are  constructed  from  the  tack  verification  matrix. 

In  the  Planning  Subsystem  a  new  concept  of  task  verification  evolved  because 
many  tasks  contained  a  large  number  of  programs  and  simultaneous  verification 
of  all  programs  at  one  time  was  found  to  be  not  feasible.  *11118  concept  is 
called  component  verification,  and  is  the  verification  of  a  portion  of  a  task 
at  a  time.  For  example,  assume  that  a  task  consists  of  programs  A,  B,  C,  D 
and  EF  One  component,  then,  might  consist  of  programs  A  and  B,  another  of 
programs  C  and  D,  yet  another  of  C,  D  and  E,  and  finally,  the  largest  component 
of  A,  E,  C,  D  and  E.  When  tasks  are  verified  in  this  fashion,  the  task  veri¬ 
fication  matrix  developed  for  verifying  components  smaller  than  the  total  tack 
is  based  on  subsets  of  the  sequence  parameters  which  make  up  the  total  task. 

M 

Upon  completion  of  the  test  lists,  the  inputs  (needed  to  activate  the  specified 
sequence  parameters  and  operate  the  tests)  are  devised  and  recorded.  The 
subsystem  verification  model  data  previously  employed  in  program  verification 
are  again  used.  Their  usage  in  both  program  and  task  verification  minimizes  the 
need  for  manually  calculating  expected  outputs  during  tack  verification,  since 
the  outputs  calculated  during  program  verification  can  be  used. 

Any  expected  outputs  which  have  not.  been  computed  during  program  verification 
are  now  computed.  All  expected  outputs  are  recorded. 

The  task  verification  plan  is  now  complete.  It  is  reviewed  for  accuracy  and 
completeness  by  the  technical  supervisor  and  changes  are  made  as  needed.  As 
in  program  verification,  test  weights  are  applied  to  enable  the  manager  to 
more  closely  assess  progress. 


Utu  <  Z 
OOOUI 


63- 


m-Lc-Sio/ioi/oo 


IT  Hay  1963 


The  second  step  in  task  verification  is  the  actual  verification  on  *he  computer. 
This  key  step  in  the  production  process  requires  many  functions  to  be  performed. 

First  -  utilizing  the  JOVIAL  program  decks,  every  program  is  recompiled  with 
the  sane  version  of  the  Coopool  (i.e.,  data  dictionary.)  This  step  is  very 
important  since  the  Compool  changes  fairly  often  and  all  programs  oust  reflect 
the  sane  data  definitions.  Hie  results  of  the  compilations  are  binary  program 
decks. 

Second  “  is  the  completion  of  the  coding  of  task  parameters.  (There  are  two 
kinds  of  task  parameters,  the  sequence  parameters  previously  mentioned,  and 
i/Q  parameters.  I/O  parameters  completely  define  the  I/O  operations  the  task 
performs.)  The  task  parameters  are  coded  and  symbolic  decks  and  listings  are 
produced.  These  are  then  submitted  for  assembly,  which  results  in  a  task 
parameter  binary  deck  and  listing. 

At  this  time  the  i/o  Assignment  cards  are  prepared.  The  System  Control  Program 
(the  Executive),  when  initiating  a  task,  first  checks  the  mounted  tapes  against 
the  assignments  specified  an  these  cards. 

Third  -  is  the  generation  or  updating  of  the  System  Master  Tape  with  the  binary 
task  parameter  and  program  decks. 

Fourth  -  is  the  generation  of  data  environment.  In  devi  sing  the  verification 
plan,  the  inputs  were  simply  recorded  on  paper.  The  function  of  this  step  is 
to  generate  this  same  data  on  tape  or  disc. 

Fifth  -  is  the  actual  operation  of  the  task  for  the  purpose  of  determining 
whether  the  initial  environment  was  correctly  established  by  the  Executive. 

The  initial  environment  consists  of  all  programs  and  data  which  are  to  be  in 
core  when  the  task  begins  to  operate. 

The  last  step  is  the  complete  operation  pf  each  test  of  the  task  on  the 
machine.  As  in  program  verification,  the  expected  outputs  are  compared  with 
the  actual  computer  outputs.  Causes  of  variances  are  determined,  changes  are 
made  and  the  task  is  rerun  until  the  actual  outputs  match  the  expected  outputs. 
When  all  actual  and  expected  outputs  agree,  the  task  is  considered  to  be 
verified. 
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Release  Phase 


Thi.  Phase  consists  of  the  "pecKaging*  of  decks,  listings,  tapes,  and if”™;3 

W  SSlSTS.  subsystem,  and  delivery  of  IKe “s' “JZSffi. 

that  Vila  perform  subsystem  testing  and  Installation  on  the  user  s  comput  t 

ttl.  Phase  is  of  great  imports-  “  ^ty^st^'^flutir 
dome  extremely  veil,  resulting  In  a  Mgh  gM^  y  assembled,  sequenced, 

attention  is  given  to  the  manner  In ^i'i^f^e.si^tSt^n  pirslJt  In 

-St' •=&£  surs-js  as  ?=?-»<» 

the  caae. 

apally  important  Is  the  documentation.  Documents  pe<fozm  several  functions  -- 
l)  they  gi  ve  a  general  overview  of  the  subsystem; 

a)  they  present  the  specific  methods  (to  operators  and  programmers)  for  scvoally 
running  the  system  on  the  computer; 

3)  they  present  the  specific  methods  by  which  the  users  will  actually  use  the 
system; 

j  \  thev  8i>eclfY  (via  flow  diagrams,  coding  specifications,  etc.)  how 

s  silts  sri  rra  asstrss;  - 

In  internal  Release  And  Their  Solution 

Pcrhap.  the  main  problem  is  that  all  toooften,  the  *£££“££.*5^ 
is  not  regarded  In  Its  true  light  .  .  .  ‘hs“'-^'  ”^  b  pacing  a  good 

jss* xsrs  as  »»» 

ents  are  released  in  an  orderly,  organised  manner. 

Our  solution  has  been  to  procedures  this  phase,  thu.  Insuring  that  all  neces. 
aary  ateps  are  followed  without  exception. 
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Methodology  Of  Internal  Release 

Hiis  phase  consists  of  producing  card  decks  and  tapes,  and  writing  the  nccecrary 
documentation.  Some  of  the  documents  will  already  have  been  written  in  previous 
phases  of  the  production  process,  and  would  only  need  to  be  updated  at  the 
Release  phase.  Other  documents,  the  contents  of  which  depend  on  the  results  of 
the  final  phases  of  verification.,  are  considered  part  of  the  release  package; 
however  they  will  not  be  completed,  until  several  weeks  after  the  Internal 
Release  Phase. 

The  Release  Package  consists  of  card  decks,  tapes,  and  documentation.  All  decks 
are  accurately  Identified.  They  are  assigned  version  numbers  which  will  be 
updated  each  tine  a  deck  modification  is  made.  TWe  decks  included  in  the  Release 
Package  are: 

Symbolic  JOVIAL  Program  Decks 
Binary  Program  Decks 
Symbolic  Task  Parameter  Decks 
Binary  Task  Parameter  Decks 

Only  one  tape  is  a  part  of  the  Release  Package.  It  is  the  System  Master  Tape 
and  contains  the  Executive  programs,  tue  necessary  su'  port  programs  and  tasks, 
and  all  of  the  k65L  Planning  Subsystem  programs  and  tasks. 

Documentation  is  the  last  part  of  the  Release  Package.  It  consists  of  the  more 
significant  documents  produced  in  the  various  phases.  More  precisely,  it  con¬ 
sists  of: 

An  Over-all  Index  And  Guide  To  Final  Documentation 

Final  Program  Subsystem  Specification 

Data  Organization  Documentation 

TaSk  Design  Specifications 

Program  Design  And  Coding  Specifications 

Computer  Operator  Manuals 

It  should  be  noted,  of  course,  that  the  group  which  has  produced  the  subsystem 
does  not  divest  itself  of  responsibility  after  Internal  Release  is  completed. 

This  group  continues  with  on-going  maintenance  responsibilities  for  a 
specified  period. 
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In  tills  paper,  ve  hove  documented  the  actual  management  methods  and  controls 
used  to  produce  the  465L  Planning  Subsystem.  A  question  that  will  inevitably 
arise  Is  -  How  such  time  should  this  production  process  take,  and,  g  vea  an 
estimate  of  the  size  of  the  program  system  to  be  produced,  how  many  programmers 
are  needed? 

The  authors,  of  this  paper  have  built  up  an  extensive  body  of  experief.ee  concerning 
these  questions.  Ve  plan  to  document  the  results  of  this  experience  in  a  future 
paper,  to  be  devoted  to  time  phasing,  scheduling,  and  budgeting.  However,  ve 
would  not  want  to  conclude  the  present  paper  without  touching  on  these  topics. 

Our  experience  indicates  that  the  total  production  process  for  the  Initial 
development  of  a  large-scale  computer  program  system  should  take  a  minimum  of 
twelve  months.  (By  initial  is  meant  the  first  time  that  the  system  is  produced. 

If  the  sss*e  system  is  la  ’Vfr  updated,  expanded,  or  otherwise  revised,  the  time 
phasing  would  most  likely  be  less  than  twelve  months. }  This  assumes  adequate 
manpower,  computer  time,  and  so  forth.  We  believe  that  the  relative  weight  to 
be  placed  on  each  phase  is  as  follows  (of  course,  there  will  necessarily  be  same 
overlapping  of  the  phases): 


Translation  Phase  1  month 
Design  Phase  3  months 
Coding  Phase  1  month 
Verification  Phase  6  months 
Internal  Release  Phase  1  month 


Furthermore,  our  experience  indicates  that  a  useful  working  figure  is  to  assume 
that  production  will  be  at  the  rate  of  12  machine  instructions  per  man  per  day 
(assuming  average  level  of  programming  experience);  or  2U0  machine  instructions 
per  month  assuming  20  working  days  per  month(thi»  takes  into  account  vacations, 
holidays,  etc.,  during  the  year.)  It  should  be  made  clear  that  this  production 
rate  covers  the  entire  period  from  the  start  of  Translation  to  the  conclusion 
of  Internal  Release. 

Of  course,  the  figure  of  12  machine  instructions  per  man  per  day  is  one  that 
will  inevitably  be  increased  as  the  production  process  becomes  better  defined, 
and  as  the  programming  state-of-the-art  advances.  Also,  the  minimum  twelve 
month  time  span  may  be  able  to  be  reduced. 

Assume  that  a  manager  is  to  produce  a  computer  program  eystem,  which  it  is 
estimated  will  contain  72, OX  instructions  (this  estimate  must  be  the  result  of 
extensive  data  processing  experience. )  Using  the  rate  of  12  machine  instructions: 
per  mar.  per  day,  ve  arrive  at  &  needed  manpower  figure  of  25  programmers  for  12 
months.  Using  the  Time  Phasing  chart  above,  the  manager  can  develop  detailed 
work  plans  and  thus  keep  close  check  on  whether  the  schedule  is  being  adhered  tc. 
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VIII.  CONCLUSION 


"Good  order  is  the  foundation  of  all  good  things. H 

-  Edmund  I'urke 


The  ^ison  d’etre  for  the  existence  of  computer  program  systems  Is  that  they 
perform  intricate  calculations  far  more  rapidly  and  accurately  than  human 
beings.  A  computer  program  system  operates  in  an  orderly  fashion,  at  lighten¬ 
ing  speed. 

But  in  order  to  produce  a  good  program  system,  managers  must  themselves 
utilize  a  system  of  production,  or  what  ve  have  termed  in  this  paper  a 
"production  process."  We  might  say  that  managers  need  a  "system  for  the 
system"  which  will  help  them  to  produce  the  best  computer  program  system 
possible,  at  optimal  time  and  manpower  costs. 

In  this  paper,  we  have  delineated  such  a  system,  consisting  of  five  primary 
phases:  Translation,  Design,  Coding,  Verification,  and  Release.  Of  course, 
we  make  no  claims  that  these  five  phases  constitute  the  "perfect"  management 
system  for  producing  a  large-scale  computer  program  system.  No  doubt,  with 
the  passage  of  time  and  the  achievement  of  further  experience,  better  "systems 
for  the  system"  will  be  evolved.  Indeed,  the  authors  of  this  paper  are  seeking 
to  refine  and  improve  the  system  documented  in  this  paper. 

As  we  visualize  it,  the  role  of  this  paper  is  two-fold: 

1.  To  emphasize  that  as  computer  program  systems  beease  larger  and 
more  complex,  it  is  imperative  that  managers  have  a  carefully 
conceived,  workable  plan  for  the  production  process. 

2.  To  make  available  our  experiences  in  managing  the  production  of 
a  300,000  instruction  computer  program  system. 

It  is  our  hope  that  this  description  of  how  the  U6%  Planning  Subsystem  is 
being  produced  will  stimulate  other  managers  to  publish  the  systems  they  use 
for  producing  their  large-scale  program  systems.  With  thia  cross-fertilisation 
of  ideas,  techniques,  and  actual  experiences,  the  state-of-the-art  can  be 
significantly  advanced. 
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46%  SYSlfili**  The  46%  System  Is  the  Strategic  Air  Conaaand  Control  System.  It 
la  a  large-scale,  computer-based  program  system" that  is  being  desired  and 
progressed  by  the  System  Development  Corporation,  in  cooperation  with  other 
organisations,  for  use  by  the  Strategic  Air  Commend. 

CCHFO0L  -  CawBuni cations  Tag  Pool.  This  is  a  collection  of  information  re¬ 
lating  alTltea  tags,  table  tags,  constants,  and  parameters  to  absolute 
storage  locations  in  core  memory,  or  auxiliary  storage.  A  coapool  may  take 
the  form  of  a  magnetic  tape,  a  deck  of  punched  cards,  or  a  printout. 

EXECUTIVE  -  This  is  a  set  of  support  programs  which  was  especially  designed  to 
control  the  operation  of  the  Planning  and  Control  programs  which  comprise  the 
46%  System.  Specifically,  the  Executive  controls  input/output  operations, 
sequencing  of  programs,  and  so  forth. 

FUNCTIONAL  AREA  -  Each  major  subdivision  of  the  Planning  Subsystem,  as  derived 
from  the  GUI's.  The  basic  criterion  employed  in  defining  logical  subdivisions 
is  the  functional  interdependency  of  individual  functions.  (Refer  to  Trans¬ 
lation  Phase,  Step  1.) 

FUNCTIONAL  FLOW  CHART  -  This  is  a  form  of  documentation  which  helps  insure 
that  the  analysis  (Translation  Phase,  Steps  1,  2  and  3)  is  performed  correctly. 

It  signifies  completion  of  analysis,  and  is  essentially  a  graphic  presentation 
of  the  prose  statement  of  requirements.  Programmers  are  required  to  produce 
functional  flow  charts  for  each  OSF.  (Refer  to  Translation  Phase,  Step  3«) 

JOVIAL  -  This  is  the  higher- level  programming  language  that  has  been  developed 
at  the  System  Development  Corporation,  and  is  being  used  in  the  46%  System. 

LOGICAL  TASK,  LOGICAL  JCB  -  Logical  task  is  the  same  as  the  (actual)  task 
defined  below.  It  is  the  task  in  a  preliminary  stage  of  development.  The 
primary  distinction  is  that  machine  constraints  have  not  yet  been  considered. 
Similarly,  a  logical  job  is  an  (actual)  Job.  It  is  the  Job  in  a  preliminary 
stage  of  development,  for  which  rachine  constraints  have  not  yet  been  considered. 

ODR  SUBFUNCTION  (OSF)  -  An  OSF  ir  ~  further  breakdown  of  a  FUNCTIONAL  AREA. 

The  purpose  of  breaking  down  fiu  *onai  areas  into  OSF’s  is  to  distribute  the 
work-load  to  programmers  on  an  equitable  basis.  (Refer  to  Translation  Phase, 
Step  2. ) 
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OPERATIONAL  DESIGN  REQUIREMENTS  (ODR'c)  -  These  documents  constitute  the 
information  base  for  the  production  process.  They  are  the  priaary  Inputs 
(along  with  the  System  Integration  Document)  to  the  Translation  Phase. 

ODR’s  contain  the  following  sections:  general  statement  and  description 
of  the  requirements;  logical  designs,  including  assumptions,  in  both  prose 
and  diagram  form;  specific  requirements  indicating  the  areas  of  human 
interaction  with  the  machine;  specific  operational  program  requirements. 
(Refer  to  Introduction.) 

PRELIMINARY  PROGRAM  SUBSYSTEM  SPECIFICATION  -  This  document  incorporates 
the  results  of  the  Translation  Phase.  It  identifies  the  logical  tasks  and 
jobs,  the  data  sets,  and  the  input  and  output  requirements  of  the  subsystem. 
It  also  contains  prose  and  graphic  descriptions  of  the  manner  in  which  the 
various  logical  tasks  and  jobs  relate.  Publication  of  this  document  signals 
the  completion  of  the  Translation  Phase.  (Refer  to  Translation  Phase, 

Step  5. ) 
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PROGRAM,  TASK,  JOB  -  The  definition  of  a  program  is  that  which  is  standard 
throughout  the  programming  profession.  A  task  is  a  set  of  computer  programs 
and  associated  data  environment,  designed  to  fulfill  specific  requirements 
stated  in  a  part  of,  or  one  or  more  ODR's.  Each  set  (i.e.,  each  task)  is 
discrete  in  that  it  has  a  unique  identification,  a  definite  beginning  end 
end,  and  operates  relatively  independently  of  other  sets.  A  job  (for  the 
Planning  Subsystem)  is  defined  as  a  set  of  tasks  (this  "set”  may  be  com¬ 
prised  of  one  or  more  tasks)  that  will  perform  the  functions  called  for  by 
a  "communication  request"  (a  "communication  request"  is  the  means  by  which 
the  k65L  Planning  Subsystem  is  utilized  by  SAC  personnel.  They  input  to 
the  computer,  via  card  inputs  or  a  keyboard,  requests  for  specific  functions 
that  are  to  be  performed  by  the  Planning  Subsystem.  These  arc  called 
"communication  requests",  and  it  is  the  job  that  fulfills  these  requests.) 
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EYSTIM  INTEGRATION  DOCUMENT  -  This  document  is  produced  before  the  start 
of  the  production  process  as  defined  in  this  paper,  and  is  thus  one  of  the 
inputs  to  the  Translation  Phase.  It  specifies  the  formats  of  the  user 
input  messages  and  of  output  displays.  (Refer  to  Introduction.) 

TABLE,  ITEM  -  A  table  is  a  definite  allocation  of  core  memory  or  auxiliary 
storage  registers  for  the  storage  of  specified  information.  An  Item  con* 
sists  of  one  or  more  bits  in  a  table,  set  aside  for  the  storage  of  specified 
information. 
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